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METHOD AND SYSTEM FOR MATCHING REMITTANCES TO 
TRANSACTIONS BASED ON WEIGHTED SCORING AND FUZZY LOGIC 



FIELD OF THE INVENTION 
5 Embodiments of the present invention relate to the field of business 

technology. Specifically, embodiments of the present invention relate to a method 
and systems for matching remittances to transactions based on weighted scoring and 
fuzzy logic. 

10 BACKGROUND OF THE INVENTION 

Companies and other entities that deploy and use computer financials 
applications use services to process payments from their own customers. These 
services are commonly known as lockbox services. Lockbox services allow 
business entities to take advantage of economies of scale available at financial 

1 5 institutions such as banks. The business entity takes advantage of these economies 
of scale by consolidating their payment processing with that of the financial 
institution's other clients. 

Some conventional lockbox technologies use a row-by-row (e.g., payment 
20 line-by-payment line) processing paradigm. However, a row-by-row processing 
paradigm can be difficult to maintain. Further, logic based on the summarization of 
payments can be difficult to implement with this conventional method. However, 
financials applications developers may for example, want to create trade deductions 
for a given invoice based on the final sum of all payment lines for the invoice, which 
25 could be troublesome to implement conventionally. 
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Typically, most lockbox files are created by human data-entry clerks. Thus, 
lockbox files are prone to typographical and other related errors. One significant 
limitation of lockbox solutions in general is the incapability of the lockbox solutions to 
handle user error. Also, to participate in lockbox remittance handling, a business 
5 entity typically may request that its customers mark their remittances with a unique 
identifier or another identifying feature, such as an identifying number or other such 
marker. Sometimes, the marker is be placed in a particular location on the remittance. 

How customers respond to a billing entity's request for marking their 
1 0 remittances with an identifying number depends on several factors. One such factor 
is that customers cooperatively respond to the entity's request. Where customers 
willingly provide the requested identifying marker, other issues can arise that may 
hamper the lockbox remittance handling efforts. For instance, the marker may not be 
placed in the requested or most ideal location: customers may place the identifier 
1 5 based on their own whims and judgment, which can be error prone. 

In order to utilize and bolster their lockbox remittance handling efforts, 
business entities and business financials applications developers have engaged in 
on-going efforts to work around these issues. Conventional efforts to correctly (e.g., 
20 accurately and precisely) match a remittance to the transaction it is intended to pay 
have generally aimed at attempting to render an exact match between the 
identifying number provided by the customer to a variety of the possible identifying 
numbers or other identifiers associated with a transaction. 

25 Conventionally, the amount of a payment and the identity of the customer 

remitting it are also typically taken into consideration when matching the remittance to 
a transaction. In conventional approaches to correctly match a remittance to the 
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transaction it is intended to pay, users also typically have to provide an order of 
significance of the types of identifying numbers to be matched. For instance, one 
exemplary possible user selected hierarchy can be to match against invoice 
numbers first; if that fails, match against sales order numbers, and so on. 

5 

These conventional workarounds however require precise entry of the 
identifying information, which as discussed above is prone to error. Conventional 
techniques also tend to discard possible matches because of inflexibility inherent in 
the selection of ordering hierarchy, such as what types identification numbers are 
1 0 tried. For instance, customers may sometimes remit amounts other than the invoiced 
amount. Thus, inflexible conventional techniques may discard matches because the 
payment amounts are not equal to the amount due remaining on the transaction. 

The inability to accurately and precisely match a remittance with its correct 
1 5 corresponding transaction can be costly. A business entity may forestall applying 
the remittances until the correct match is made. Delay in applying the remittances can 
result in concomitant delay in availability of funds. Where a match is not returned on 
the basis of information supplied with the remittance, direct human intervention can 
be required in the form of research conducted, which can be painstaking, in order to 
20 match the remittance and transaction. Costs of such research can be significant. 

Thus, conventional approaches matching remittances to transactions that are 
undertaken by business entities can be inadequate. Their processing paradigm can 
be difficult to maintain and can deter use of logic based on the summarization of 
25 payments. They are prone error. Identifiers used to match remittances to particular 
transactions may be misplaced by customers and then overlooked by the receiving 
entity. Conventional workarounds are constrained by inflexibility, such that they 
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discard or overlook information that can result in proper matches between the 
remittance and the transactions to which they should be matched. 
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SUMMARY OF THE INVENTION 

A method is needed that can match remittances to transactions that uses a 
processing paradigm that is not complicated to maintain and fosters the use of logic 
based on the summarization of payments. A system and/or method is also needed 
5 that can match remittances to particular transactions with relaxed sensitivity to where 
identifying markers are placed on a remittance and that is resistant to typographical 
data entry errors. Further, a system and/or method is needed that can match 
remittances to transactions that is flexible with regards to handling various kinds of 
information that can result in accurate, precise matching without discarding or 
1 0 overlooking such information. 

A method for matching remittances to transactions is disclosed. The method 
for matching remittances to transactions disclosed herein uses a processing paradigm 
that is easy to maintain and fosters the use of logic based on the summarization of 

1 5 payments. The method disclosed herein also matches remittances to particular 

transactions with relaxed sensitivity to where identifying markers may be placed on a 
remittance and is resistant to typographical data entry errors. Further, the method 
disclosed herein is flexible with regard to handling various kinds of information that 
can result in accurate, precise matching without discarding or overlooking such 

20 information. 

Computing power is currently available to business entities that can process 
large, even massive amounts of data in a cost-effective manner. Business entities 
currently have access to computers that have gigabytes of main memory at 
25 reasonable prices. Such low cost, high power and capacity computing resources 
allow implementation of computing paradigms such as those which can effectuate 
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practical computation with imprecise data and on problems with non-unitary solutions. 
One such computing paradigm utilizes fuzzy logic. 

One embodiment of the present invention implements a novel approach to 
5 lockbox remittance-to-transaction matching. The present embodiment takes 
advantage of the aforementioned currently available computing capacity to load all 
pertinent matching information into computer memory and process the information in 
memory using a fuzzy logic matching process that can compensate for inaccuracies in 
the data. In one embodiment, issues related to discarding possible matches due to 
1 0 the strict hierarchical order of identification numbers or the mismatch of the payment 
amount are solved by evaluating a substantial majority of possible matches. 

In one embodiment, this evaluation proceeds using weights specified by the 
user. This evaluation provides a substantially comprehensive picture of effectively 
1 5 all possible matching invoices. Further, this evaluation prevents a possible match 
from being removed from consideration by an unfavorable hierarchy of identification 
numbers or an unfair weighting of the payment amount. 

In one embodiment, a computer implemented method matches a remittance 
20 to a transaction by receiving remittance lines, transaction information, and matching 
rules wherein the matching rules assign a weight to a parameter considered in the 
matching, computing a weighted matching score corresponding to the parameter 
based upon that weight wherein the matching score corresponds to a probability of 
an accurate and precise match between the remittance and the transaction, and 
25 generating a match recommendation based on that weighted matching score. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and form a part of this 
specification, illustrate embodiments of the invention and, together with the 
description, serve to explain the principles of the invention. 

5 

Figure 1 depicts a system for matching remittances based on weighted 
scoring and fuzzy logic and flow there through, according to one embodiment of the 
present invention. 

1 0 Figure 2 is a flowchart of an exemplary process for generating matching 

recommendations, according to one embodiment of the present invention. 

Figure 3 illustrates an exemplary interpretation a matching program can make 
of valid lockbox lines, according to one embodiment. 

15 

Figure 4 depicts an exemplary scoring structure, which is used to calculate a 
weighted matching score according to one embodiment of the present invention. 

Figure 5 is a flowchart of an exemplary process wherein weighted scores are 
20 computed, according to one embodiment of the present invention. 

Figure 6 depicts a determination of a customer score, according to one 
embodiment of the present invention. 

25 Figure 7 depicts a determination of a transaction score, according to one 

embodiment of the present invention. 
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Figure 8 depicts a determination of a customer identifying score, according to 
one embodiment of the present invention. 

Figure 9 depicts a determination of a customer name score, according to one 
5 embodiment of the present invention. 

Figure 1 0 depicts a determination of a bank score, according to one 
embodiment of the present invention. 

1 0 Figure 1 1 depicts a determination of a transaction number score, according to 

one embodiment of the present invention. 

Figure 12 depicts a determination of a transaction amount score, according to 
one embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

A system and method for matching remittances based on weighted scoring 
and fuzzy logic is disclosed. Reference will now be made in detail to several 
embodiments of the invention, examples of which are illustrated in the 
accompanying drawing figures. While the invention will be described in conjunction 
with these embodiments, it will be understood that they are not intended to limit the 
invention to these embodiments. On the contrary, the invention is intended to cover 
alternatives, modifications and equivalents, which may be included within the spirit 
and scope of the invention as defined by the appended claims. 



Furthermore, in the following detailed description of the present invention, 
numerous specific details are set forth in order to provide a thorough understanding 
of the present invention. However, one of ordinary skill in the art will realize that 
embodiments of the present invention may be practiced without these specific 
1 5 details. In other instances, well-known methods, processes, algorithms, procedures, 
networks, systems, components, and circuits have not been described in detail so 
as not to unnecessarily obscure aspects of the present invention. 

A computer system that embodies a system and performs a method for 
20 matching remittances to transactions can comprise any kind of computer system with 
sufficient computing power and memory capacity. For example, the computer 
system can comprise a workstation computer system, a personal computer system, 
a specialized business and financial computing system, a main-frame computer 
system, or a supercomputer system. Modules of the system for matching 
25 remittances to transactions can be implemented in software, firmware, and/or 
hardware or any combination of software, firmware, and/or hardware. 
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Portions of the detailed descriptions of embodiments of the invention that 
follow are presented and discussed in terms of processes. Although specific steps 
and sequence thereof are disclosed in figures herein (e.g., Figure 2, Figure 5) 
describing the operations of these processes (e.g., processes 200, 500), such 
5 steps and sequence are exemplary. Embodiments of the present invention are 
well suited to performing various other steps or variations of the steps recited in the 
flowcharts of the figures herein, and in another sequence than the sequence depicted 
and described. 

1 0 In one embodiment, such processes are carried out by processors and 

electrical/electronic components under the control of computer readable and 
computer executable instructions comprising code contained in a computer usable 
medium. In one embodiment, a graphical user interface (GUI) is also effectuated by 
such processors and components under the control of computer readable and 

1 5 computer executable instructions. The computer readable and computer 
executable instructions reside, for example, in code within a computer usable 
medium and used in the processor, data storage features, memory, registers and 
other components of a computer system performing the method for matching 
remittances to transactions. However, the computer readable and computer 

20 executable instructions may reside in any type of computer readable medium. 

One embodiment of the present invention provides significant reduction in 
miss rate (e.g., failing to accurately and precisely match a remittance to a correct, 
corresponding transaction). Advantageously, use of the present embodiment by a 
25 business entity can provide a business entity user with a significant savings in what 
must conventionally be expended on research costs associated with unapplied 
receipts (e.g., research conducted by trained personnel to correlate 
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unmatched/mismatched receipts to their correct corresponding transactions). Further 
financial advantages can accrue to the concomitant ability to more quickly apply 
remittances received, once they are matched to their respective transactions. 

5 Exemplary System for Matching Receipts 

Figure 1 depicts a computer-based system 1 00 for matching remittances 
based on weighted scoring and fuzzy logic and flow there through, according to one 
embodiment of the present invention. A graphical user interface (GUI) provides a 
plurality of matching rules setup screens 101 that allow a scoring model to be 
1 0 programmed. The computer controlled by the setup screens 1 01 provided by its 
GUI outputs a set of matching rules 1 02. Matching rules 1 02 specify the scoring 
model programmed by interactive setup screens 101 that stipulate the weight (e.g., 
relative scoring significance) that a variety of conditions and attributes will hold 
individually and with respect to each other. 

15 

A data staging program 106 stages data such as receivables data retrieved 
from a database 105. The receivables data comprises information that is relevant to 
matching remittances to corresponding transactions, based on weighted scoring and 
fuzzy logic. Data staging program 106 provides the information 107 that it stages to 
20 a matching program 1 1 0. 

Matching program 1 10 receives matching rules 102 from setup screens 101 
and the staged transaction information 107 from data staging program 107. Further, 
matching program 110 receives data from lockbox file 109. Matching program 110 
25 then matches transactions to remittance lines to match remittances to the transactions. 
In one embodiment, matching program 1 10 uses weighted scoring according to 
rules 102 and applies fuzzy logic to effectuate the matching. Upon computing 
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matches for remittance lines to their respective transactions, matching program 110 
provides application recommendations 1 1 1 to a post-match handler 120. 



Upon receiving application recommendations 111, post match handler 
5 (applier) 1 20 calls a receipts application program interface (API) 1 30 of an 
applications database to create corresponding receipts and apply matched 
remittances to appropriate transactions. In the event of unmatched remittances, 
post-match applier 120 calls a notification initiator 140 to handle them. 

1 0 Receipt AP1 1 30 assigns an informative header to a receipt for use by a 

receipt application 131 . Where the remittance line corresponding thereto in lockbox 
file 109 matches more than one customer (e.g., remitter), receipt AP1 130 assigns an 
appropriate receipt header to receipts. 

1 5 Notification initiator 1 40 initiates a workflow notification 1 41 to a user entity 1 42 

where matching program 1 10 does not determine a match for a remittance to a 
transaction. 

Exemplary Process for Generating Match Recommendations 
20 Figure 2 is an exemplary flowchart of a computer-based process 200 

wherein a matching program (e.g., matching program 110; Fig. 1) generates 
matching recommendations, according to one embodiment of the present invention. 
Process 200 begins with step 201 , wherein the matching program receives 
matching rules, transaction information, and information from a lockbox file (e.g., 
25 matching rules 1 02, staged transaction information 1 07, lockbox file 1 09; Fig. 1 ). 
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In step 202 of Figure 2, the matching program computes a weighted 
matching score for a remittance to a transaction. The matching program can compute 
the weighted matching score in several ways. In one embodiment, the matching 
program computes the weighted matching score by a process in which scores are 
5 computed over a number of parameters, each of which is weighted, strings 

comprising the multiplicity of weighted scores over the parameters are scored and 
combined, and a total score computed therefrom. One such process (e.g., process 
500; Fig. 5) is discussed below. 

1 0 In step 203, the matching program generates application recommendations 

of possible matches for use by a post match handler (e.g., post-match handler 120; 
Fig. 1). The recommendations may be based on the weighted matching score 
calculated, e.g., the higher the weighted score, the more probable it is that a particular 
remittance matches (e.g., corresponds to) a particular transaction. 

15 

In step 204, it is determined whether exceptions are encountered, such as 
scores falling below a match threshold. If it is determined that exceptions are 
encountered, then in step 205, the exceptions are handled. 

20 In one embodiment, exceptions are handled by attempting to match a 

remittance against multiple transaction invoices. In one embodiment, matching the 
remittance against multiple transaction invoices is performed using a process 
employing a heuristic such as a Knapsack Heuristic, wherein the sum of the invoices 
is matched as closely as possible to the amount of the remittance. 

25 

Upon handling the exceptions (or if no exception is encountered), in step 
206, the applications are handled, upon which process 200 is complete. In one 
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embodiment, a post-match handler calls a receipt API with the matches and a 
notification initiator if no matches are found (e.g., post-match handler 120, receipt API 
130, notification initiator 140; Fig. 1). 



5 In performing process 200, according to one embodiment, the matching 

program takes the given lockbox file (e.g., lockbox file 109) and attempts to match 
the remittance lines contained therein to the data on transactions extracted by the 
data staging program (e.g., staged transaction information 107, data staging program 
106; Fig. 1). In order to find the best match for a given remittance, all transactions 

1 0 selected by the staging program may first be scored. 

The transaction with the best score is then selected and compared to a global 
match threshold defined by the user during set up in one example. If the score is 
equal to or above the given threshold, then the match is considered valid and is 
1 5 passed on to the receipt application program for processing. If the score is below 
the given threshold, the match is not considered valid. 



Transmission Format definitions currently available in, for example a 
receivables application, are leveraged in one embodiment to control the manner in 

20 which the lockbox file is read from the file system. For instance, a user specifies the 
location and name of the lockbox file in a lockbox file parameter, and the format of 
the file using the transmission format parameter. In order to minimize memory use, in 
one embodiment the matching program (e.g., matching routine) first spawns a 
program to read the cognizant transmission format specifications from a database to 

25 a format specification file. This format specification file will then be used by the main 
matching program to read the lockbox file. 



ORCL-2003-030-01/ACM/GDB/LRG 



14 



The lockbox transmission format specification file outlines to the main matching 
routine how to read the given lockbox file. Internal lockbox record entries store 
payment information for use during the matching and application phases . The fields 
5 in the lockbox record should correspond to fields defined in a transmission formats 
window. Table 1 below lists exemplary transmission format fields included in the 
lockbox record of one embodiment. It is appreciated that the fields in Table 1 
below are exemplary; some of these fields may be omitted and/or other fields may 
be included in the lockbox record, in another embodiment. 

10 



Table 1 



Account: the payer's bank account. The bank account number and the transit 
routing number make up the payer's magnetic ink character recognition (MICR) 
number. 

15 

Amount Applied 1 to 8: The amount applied to each invoice, debit memo, or 
chargeback in the transaction currency. Each payment or overflow payment record 
can accommodate up to eight debit item numbers in one example. For cross 
currency applications, this can be the amount to apply in the transaction currency and 
20 corresponds to the Amount Applied field in the Applications window. 



Bank Transaction Code: A code defined for each account that is used by the 
bank to uniquely identify the kind of transaction in a bank statement (for example, 
debit, credit, void). This is also used by a cash management application or similar 
25 application to determine a receipt's effective date. 



Customer Bank Branch Name: The name of the customer's bank branch. 



Customer Bank Name: The name of the customer's bank. 

30 

Customer Number: The identification number of the customer who submitted 
a payment. 



Deposit Date: The date the bank receives and deposits the customer's 
35 payment. 
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Effective Date: The date on which the bank determines a customer's balance 
to apply interest (used by a cash management application's forecasting feature). 



5 Invoice 1 to 8: The invoices, debit memos, and chargebacks to which a 

business entity applies the payment. Each payment or overflow payment record 
can accommodate up to eight debit item numbers. 

Invoice 1 to 8 Installment: The installment number for this invoice. 

10 

Lockbox Number: The identification number for a specific lockbox. 

Payment Method: The payment method associated to this lockbox. 

1 5 Payment Number: The identification number of a payment. For example, a 

check number. 

Receipt Date: The date the customer made a payment. 

20 Record Identifier: A number that identifies the kind of transmission record 

(e.g., Overflow Payment, Payment, Lockbox Header, etc.). 

Remittance Amount: The amount of the payment. 

25 Transit Routing Number: The number that uniquely identifies the payer's 

bank. The transit routing number and the customer bank account number make up 
the payer's MICR number. 



30 In one embodiment, the following lockbox record fields are used by the 

Matching Program to identify matches: 

Account Number (in conjunction with the Transit Routing Number); 

Amount Applied 1 to 8; 

Customer Number; 
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Invoice 1 to 8; 

Invoice 1 to 8 Installment; 

Payment Number; 

Transit Routing Number (in conjunction with the Account Number). 

In one embodiment, the following fields are used when the actual applications 
are made: 

Bank Transaction Code; 

Customer Bank Branch Name; 

Customer Bank Name; 

Deposit Date; 

Effective Date; 

Lockbox Number; 

Payment Method; 

Receipt Date. 

The matching routine reads these fields in to communicate them along with the 
applications it recommends to the application routine. 

In one embodiment, cross-currency applications are not considered. In the 
present embodiment therefore, the following field types (available for cross-currency 
applications) are not included in the lockbox record. The routine logs an error and 
exits immediately if any are encountered in the lockbox file: 

Amount Applied From; 
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Currency Code; 
Exchange Rate; 
Exchange Rate Type; 
Invoice Currency Code; 
5 Trans to Receipt Rate. 

In another embodiment supporting cross-currency applications, such field types can 
be considered. In one embodiment, flexfields and all other fields not mentioned 
herein are not be included in the lockbox record; they are not required to match the 
remittance or apply it to a transaction and are effectively ignored by the matching 
1 0 program. 

A format specification file that can be written by the matching routine has a format that 
can be illustrated by the exemplary lines below in Table 2. 
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Table 2 
Exemplary Code Format 



<transRecord recordtype-" [Transmission Format Record 
Type 1] 

5 identifier-" [transmission record 

identifier 1] "> 

<field type-" [field 1 type]" 

start-" [start position 1]" 
end-" [end position 1]" 
10 justification-" [justification 1]" 

pad="[pad character 1]"> 
<field type=" [field 1 type]" 

start-" [start position 2]" 
end="[end position 2] 
15 justification-" [justification 2]" 

pad-" [pad character 2]"> 

<field type="[last field type]" 

start-" [last start position]" 
20 end-" [last high char position]" 

justification-" [last justification]" 
pad-" [last pad character] "> 
</transRecord> 

<transRecord recordtype-" [Transmission Format Record 
25 Type 2] 

identifier-" [transmission record 
identifier 2]"> 



30 



35 



</transRecord> 

<transRecord recordtype-" [last Transmission Format 
Record Type] 

identifier-" [last transmission record 

identifier] "> 
</transRecord> 



Each transRecord entry corresponds to a Transmission Record entry of the 
Transmission Format specified by the user. Each of the field entries corresponds to 

40 the Transmission Field entries that belong to the Transmission Record. The type 
attributes of the field records correspond to the value of the Field Type of the 
specified Transmission Field. The start and end attributes of the field records 
correspond to the matching start and end positions, respectively, for the given 
Transmission Field. An Extensible Markup Language (XML) schema definition for 

45 the file format is illustrated by the exemplary lines below of Table 3. 
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Table 3 

Exemplary XML Schema Definition for File Format 



<xsd: element name="transRecord" 
type="transRecordType"/> 

5 

<xsd: complexType name="transRecordType"> 
<xsd: sequence> 

<xsd: element name="f ield" type="f ieldTYpe" 

minOccurs=" 1 " maxOccurs="unbounded"> 

1 0 </xsd: sequence> 

<xsd: attribute name="recordtype" 
type="xsd : NMTOKEN " /> 

<xsd: attribute name="identif ier" 
type="xsd : NMTOKEN" /> 
1 5 </xsd: complexType> 

<xsd: complexType name="f ieldType"> 

<xsd: attribute name="type" type="xsd : NMTOKEN "/> 
<xsd: attribute name="start" type="xsd: decimal"/> 
20 <xsd: attribute name="end" type="xsd: decimal"/> 

<xsd: attribute name=" justification" 

type="xsd : NMTOKEN" /> 

<xsd: attribute name="pad" type="xsd: NMTOKEN" /> 

</xsd: complexType> 

25 

The lockbox reading routine takes the format specification file and use it to 
read the lockbox file specified by the user. The routine reads the lockbox file line- 
by-line. Each transmission line in the lockbox file ends with a carriage return and/or 
linefeed, and begins with a recognized transmission record identifier for the 
30 transmission format specified by the user. 



The program validates that none of the fields within a transRecord rule have a 
start and end position that does not overlap with another field's. The transmission 
record identifier at the beginning of a lockbox line specifies the transRecord rule to 
35 be used for reading the line. As discussed above, the transmission record identifier 
is at the beginning of the line. Although the program should expect the transmission 
record identifier at the beginning of a lockbox line, the transmission format file 



ORCL-2003-030-01/ACM/GDB/LRG 



20 



specifies, in one embodiment explicitly, the start and end position of the 
transmission record identifier, as it may be 1 or 2 characters in length. 

In one embodiment, the matching program looks at the start and end 
5 positions for each field specified and loads the corresponding lockbox record field. 
Before loading a data entry in the lockbox file into the lockbox record, the string must 
first be stripped of padding characters. The justification and pad attributes of the 
transmission format specification that corresponds to the field determines how the 
pad characters should be truncated are described in Table 4, below. 

10 

Table 4 



Pad Attribute 
Value 


Justification Attribute 
Value 


Truncation Action 


Zero 


Left 


Remove all zeros (0) after last non- 
zero character in the string. 




Right 


Remove all zeros (0) before the first 
non-zero character in the string. 


Blank 


Left 


Remove all whitespace after the last 
non-whitespace character in the string, 
excluding carriage returns & linefeeds. 




Right 


Remove all whitespace after the first 
non-whitespace character in the string, 
excluding carriage returns & linefeeds. 



Multiple entry fields such as Invoice 1 through 8, Invoice Installment 1 through 
1 5 8, and Amount Applied 1 through 8 each correspond to a different lockbox record 
entry from the point of view of the matching program and are loaded as independent 
records. 
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Each of the payment entries in the file will not necessarily have all of the fields 
required to completely fill in a lockbox record. For example, lockbox files can 
typically contain several overflow payment lines after a payment line, but the 
customer information for the payment will only appear on the payment line. In order 
5 to complete the lockbox record entry, the following records are searched, to fill in 
missing field values: 

the associated Transaction entry before the next Transaction; 

the associated Overflow Payment line; 

the associated Payment line; 

1 0 the associated Batch Header line; 

the associated Lockbox Header line; 

the associated Service Header line; 

the associated Transmission Header line. 

In one embodiment, these records are searched in the order specified above. 

15 

If none of these lines contain currency information, then the default functional 
currency is used. If any date value is missing, the current system date is substituted. 
If any other value is missing, then the process continues with no value in the 
corresponding field in the record. For example, one transRecord format specification 
20 is illustrated by the exemplary lines below in Table 5. 
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Table 5: Exemplary transRecord Format Specification 

<transRecord recordtype= "Payment" 
identif ier="5"> 
<field type="Record Identifier" 
start="l" 
end="l" 

justification="Left" 
pad="Zero"> 
<field type="Customer Number" 
start="2" 
end="10" 

just if ication="Left" 
pad="Blank"> 
<field type="Payment Number" 
start="ll" 
end="20" 

just if ication="Right" 
pad="Zero"> 
<field type="Receipt Date" 
start="21" 
end="28" 

justification="Lef t" 
f orma t = "MMDDY Y YY " 
pad="Blank"> 
<field type="Currency" 
start="29" 
end="31" 

just if ication="Left" 
pad="Blank"> 
</transRecord> 

<transRecord recordtype="Overf low Payment" 
identif ier=" 9 "> 
<field type^"Record Identifier" 
start="l" 
end="l" 

justification="Left" 
pad="Zero"> 
<field type="Invoice 1" 
start="2" 
end="10" 

justification="Left" 
pad="Blank"> 
<field type="Amount Applied 1" 
start-"ll" 
end="20" 

just if ication= "Right" 
pad="Zero"> 
<field type="Invoice 2" 
start="21" 
end="2 9" 

just if ication="Left" 
pad="Blank"> 
<field type="Amount Applied 2" 
start="30" 
end="4 9" 

j ust if ication= "Right " 
pad="Zero"> 
</transRecord> 
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A lockbox file (e.g., lockbox file 109; Fig. 1) comprises lockbox lines. With 
reference to Figure 3, the interpretation a matching program makes of exemplary 
valid lockbox lines 300 is illustrated, according to one embodiment. As depicted in 
interpretation field 303, lockbox line 1 , beneath column guide 301 , comprises a 
5 record identifier '5', a customer number '1 001 ', a payment number '00001 23456', 
and a receipt date '02072002', and denotes 'USD' (United States Dollars) as the 
currency. 

As depicted in interpretation field 304, lockbox line 2, above column guide 
1 0 302, comprises a record identifier '9', a first invoice identity 'INV1 23' and a 

corresponding first amount applied '0000123.45', and a second invoice identity 
'INV125' and corresponding second amount applied '0003453.98'. Upon 
interpreting the lockbox lines 300, the matching program weighs the corresponding 
parameters reflected therein according to the matching rules and transaction 
1 5 information (e.g., matching rules 1 02, staged transaction information 107; Fig. 1) and 
scores them as possible matches of varying probability. In one embodiment, a 
matching process (e.g., process 500; Fig. 5) performed by the matching program 
can follow a scoring structure. 

20 Exemplary Scoring Structure 

Figure 4 depicts an exemplary scoring structure 400, which is used to 
calculate a weighted matching score according to one embodiment of the present 
invention. The weighted matching score comprises the probability of a possible 
match being accurate and precise in order to seek the best possible (e.g., the most 

25 probable accurate and precise) match between a remittance and transactions in a 
database is computed. 
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In Figure 4, a score value is denoted by '3 and a weight is denoted by 'W. 
Scores S correspond to probabilities of matching between a remittance and a 
transaction based on particular parameters, such as invoice identifying numbers, 
5 other invoice information, and corresponding customer information. In scoring 
structure 400, each score S comprises a percentage calculated out of a maximum 
possible 100% for each particular parameter being scored. 



Figure 4 summarizes the components that comprise the total score S total 401 . 
1 0 At the highest level, the matching score for a transaction is a weighted average of a 
score based on transaction attributes and a score based on customer attributes. 

Weights W correspond to values for the significance of certain factors taken 
into account in scoring. These values are determined by a user and entered by a 
1 5 GUI providing matching rule setup screens to generate a matching rule (e.g., GUI 
matching rule setup screens 101, matching rules 102; Fig. 1). 



The significance a user assigns to determine a corresponding weight in 
generating a matching rule can be based on subjective and/or objective business 
20 considerations including but not limited to historical data and information specific to 
particular customers and groups of customers. The weights that are used to 
compute each score at each node of the tree are constrained in one embodiment to 
add up to 100% and reflect business rules prescribed by the user. At each node of 
scoring structure 400, weights W sum to 100%: 

25 

^ customername ^ customerlD ^ bank = ^ 00% 
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W =100% 

rr customers* ' rr customeracr iW/u 



The weights W for each parameter are multiplied by the corresponding score S for 
5 that particular parameter to generate a weighted score ' Wx S for that parameter. 

In scoring structure 400, a total score 401 comprises a weighted customer 
score 410 combined with a weighted transaction score 420. Weighted customer 
score 41 0 comprises a combining of a weighted customer name score 41 1 , a 
1 0 weighted customer identity score 41 2, and a weighted bank score 41 3. Weighted 
customer name score 41 1 comprises a combining of a weighted customer- 
associated acronym score 416 with a weighted customer string score 415. 
Weighted transaction score 420 comprises a combining of a weighted transaction 
number score 421 and a weighted transaction amount score 422. 

15 

Exemplary Process for Computing Weighted Scores 
Figure 5 is a flowchart of an exemplary process 500 wherein weighted 
scores are computed, according to one embodiment of the present invention. The 
steps described herein can be performed as discussed below in somewhat greater 
20 detail. Further, the steps and sequence thereof comprising process 300 as 

described herein are for the purpose of illustrating and describing one exemplary 
method by which weighted scores can be calculated by which a remittance can be 
matched to a transaction. 



25 These steps and their sequence are not to be construed as limiting. Other 

embodiments of the present invention are well suited to computing scores to match 
remittances to transactions using other steps and/or sequencing of steps. For 
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example, in another embodiment, the computation of a weighted transaction score 
(e.g., step 512 herein) can be performed prior to computation of a weighted 
customer score (e.g., step 508 herein). 

Process 500 begins with step 501 wherein a weighted customer string score 
is computed (e.g., calculated). In step 502, a weighted customer acronym score is 
computed. In step 503, a customer name score is computed. In step 504, a 
weighted customer name score is computed. 

In step 505, a weighted bank score is computed. In step 506, a weighted 
customer identity score is computed. In step 507, a customer score is computed. In 
step 508, a weighted customer score is computed. 

In step 509, a weighted transaction number score is computed. In step 51 0, 
a weighted transaction amount score is computed. In step 51 1 , a transaction number 
score is computed. In step 512, a weighted transaction number score is computed. 
In step 513, score components treated as strings are scored using, in one 
embodiment, a Levenshtein and Longest common substring fuzzy scoring heuristic. 
In step 514, a total score is computed. 

In step 515, it is determined whether a score (e.g., a total score) falls below a 
match threshold, which can be set by a user. If a score falls below a match threshold, 
then in step 516, an attempt is made to match the remittance against multiple 
invoices. In one embodiment, matching the remittance against multiple transaction 
invoices is performed using a heuristic wherein the sum of the invoices is matched 
as closely as possible to the amount of the remittance. Upon handling the 
exceptions (or if no exception is encountered), process 500 is complete. 
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Exemplary Score Structure Fields Illustrate Computation of Parameters 
Considering the exemplary scoring structure 400 introduced above (Fig. 4), 
the steps comprising a process for computing scores (e.g., process 500; Fig. 5) can 
5 be explained further. 

Exemplary Customer Score Computation 

Referring to Figure 6, field 600 illustrates that the customer score, ^customer . IS 
computed as a weighted average over 100% from the following components: the 
1 0 Customer Name Score and Weight (L tom e^ and ^rome™** herein, 

respectively); the Customer Identifying Number Score and Weight ^customer* and 

^ customer # herein, respectively); and the Customer Bank Account Score and Weight 

( S bank and w bank herein, respectively). As discussed above, the score is a weighted 
average over 100%; thus the weights sum up to 100%. 

15 

The customer name score, ^customemame is in turn computed as a weighted 
average over 100% from the following components: the Customer Name's String 
Score and Weight ( S cu St omerstr and w customers herein, respectively); and the Customer 
Name's Acronym Score and Weight (^omemcr and W customemcr in this document, 

20 respectively). As the score is a weighted average over 100%, the weights add up 
to 100%. 

Exemplary Transaction Score Computation 

Referring to Figure 7, field 700 illustrates that the transaction score, s t>* , is 
25 computed as a weighted average over 100% from the following components: the 
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Transaction Identifying Number Score and Weight (S trxU andW trxn herein, 

respectively); and the Transaction Amount Score and Weight (S amom and^ 0ttm 

herein, respectively). As the score is a weighted average over 100%, the weights 
sum up to 100%. The Transaction Identifying Number Score is computed based on 
5 relevance factors provided by the user. The matching program allows users to 
place a different weight on closed transactions versus open transactions and other 
such factors. 



Exemplary Customer Identifying Number Score Computation 
1 0 Depending on the practice of the deploying company's (e.g., a business 

entity that deploys an embodiment of the present invention for use in matching 
remittances to transactions) business, the Customer Identifying Number can 
correspond to either the customer account number or the customer number. In one 
embodiment, the process scores on the customer number. In another embodiment, 
1 5 the process scores on the customer account number. Yet another embodiment 
scores using both numbers. 

Referring to Figure 8, field 800 illustrates that, in order to determine the 
Customer Identifying Number score ( S customer# ), the matching program evaluates the 

20 match score between the customer identifying number provided by the customer on 
their remittance and the customer account number and the customer number. Both of 
these scores are multiplied by a user-set corresponding relevance factor. A higher 
relevance factor for the customer account number or customer number can indicate 
that the given identifying number is more likely to be used when the customer is 

25 identifying themselves. The Customer Identifying Number score (^customer* ) used in 
one embodiment to further score the transaction comprises the higher of these two 
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scores. In another embodiment, comprises a weighted average of both 

of these scores. 

Exemplary Customer Name Score Computation 
Referring to Figure 9, field 900 illustrates that the customer name score 
S customemame is comprised of the following two components: the weighted score of 
the string match between the name of the customer associated with the transaction 
and the customer on the remittance ); and the weighted score of the string 

match between the acronyms of the customer associated with the transaction and the 
customer on the remittance ( S cus,omeracr ). The Customer Name score, S aatami!mimie t \ s 
computed as a weighted average over 100% from these two components. As the 
score is a weighted average over 100%, the weights provided add up to 100%. 

Exemplary Bank Score Computation 

Referring to Figure 10, field 1000 illustrates a bank score computation. In 
order to determine the Bank score ), the matching program uses both the 
Transit Routing Number and the Account Number provided in the lockbox file. The 
matching program evaluates the match score between the concatenation of the 
Transit Routing Number and the Account Number provided by the customer on their 
remittance and the concatenation of the Customer Bank Number and Customer 
Bank Account database fields. 

Exemplary Transaction Identifying Number Score Computation 
Referring to Figure 1 1 , field 1 100 illustrates a transaction identifying number 
score computation. Customers typically identify the transaction that they want to pay 
with their remittance with an identifying number for the transaction. Depending on the 
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practice of the deploying company's business, this number could correspond to one 
of several numbers that can be used to identify the transaction, such as a transaction 
number or a bill of lading number. 

5 In order to determine the Transaction Identifying Number score (S t „# ), the 

Matching Routine evaluates the match score between the identifying number for the 
targeted transaction provided by the customer on their remittance and each of the 
following numbers on the transaction: 

Transaction Number; 
1 0 Purchase Order Number; 

Transaction Reference; 

Bill of Lading Number; 

Sales Order Number; and 

Transaction Header External System reference number. These are reference 
1 5 numbers provided by an application such as a non-receivables application in a 
transaction flexfield (or similarly functioning field or other feature therein) to help 
identify a transaction. In one embodiment, the following external system reference 
numbers are supported: 

Projects application project number; 
20 Projects application draft invoice number; 

Projects application agreement number; 

Transaction line external system reference number. These are reference 
numbers provided by a non-receivables application in its transaction line flexfield to 
help identify a transaction. 

25 

One embodiment supports external system reference numbers such as a 
Contracts application contract number, a Service application service order number, 
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and a Projects application project number. In addition, to handle installments, in one 
embodiment the matching routine can also score the following remittance against 
other transaction information. For instance, where the Installment Number is provided 
separately in the remittance, the concatenation of the identifying number on the 
remittance followed by a dash ("-") and by the installment number on the remittance 
are compared against the transaction number followed by a dash and by the 
payment schedule terms sequence number. Where the installment number is not 
so provided, the identifying number on the remittance is compared against the 
transaction number followed by a dash and by the payment schedule terms 
sequence number. 

The score obtained from matching the remittance identifying number against 
each of these transaction numbers is multiplied by the corresponding relevance 
factor that the user has set up. A higher relevance factor indicates that a given 
identifying number has more significance when trying to match a remittance to a 
transaction. In one embodiment, the Transaction Identifying Number score $*# ) 
that is used to further score the transaction will be the highest relevance-weighted 
score among all of the transaction number scores. 

Exemplary Transaction Amount Score Computation 
Referring to Figure 12, field 1200 illustrates a transaction amount score 
computation. In one embodiment, the amount score for a transaction ^amomt ) is 
derived by dividing the smaller of the amount on the transaction being considered 
and the amount of the remittance being matched by the larger of the two amounts: 
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c = minC4/?i^ ac( , on , Amt rmitimce ) 

^undiscounted - 



™A Amt transaction* A ™< rent, ton ce) 

Formula 1 



In one embodiment, this computation is modified such that discounts are taken into 
5 consideration when scoring the amount match. In field 1 200, whether the discount 
conditions have been met is not considered in scoring such matches. In the present 
embodiment, the matching routine match remittances to invoices in instances where 
customers incorrectly believe that they have met the discount conditions and they 
attempt to pay the discounted amount. 

10 

If there is a discount for the payment terms associated with the particular 
payment schedule matched against the remittance, the matching routine derives a 
discounted amount score by dividing the smaller of the discounted amount on the 
transaction and the amount of the remittance being matched by the larger of the two 
1 5 amounts: 

S d . j = ™™Umt lramac , i0 „ x{\-discount%), Amt remitt!mce ) 

^Wlttransactton *V ~ <HSCOUntVo ), Amt 

Formula 2 

The amount score is then be returned as the maximum of the undiscounted and 
20 discounted scores. 



The scores for the following score components are treated as strings: 
Customer Name ( S customentr ), which are scored using Levenshtein and 

Longest common substring fuzzy-scoring heuristics: 
25 Customer Bank and Bank Account ( s *»* t also the same as the MICR 

number); 
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Transaction Number; 
Customer Number; 
Customer Account Number; 
Purchase Order Number; 
5 Transaction Reference; 

Bill of Lading Number; 
Sales Order Number; 

Transaction Header External System reference number; 
Transaction Line External System reference number. 

10 

The Levenshtein and Longest common substring fuzzy-scoring heuristics 
comprise two different methods of evaluating the similarity between two strings. 
The Levenshtein process produces a matrix of the hamming distances between two 
strings. One embodiment reuses this matrix to efficiently compute the Largest 
1 5 Common Substring score in a reduced computation time for the Largest Common 
Substring score. This combines the Levenshtein and Largest Common Substring 
heuristics to get a more efficient implementation than what is possible if both 
heuristics are run independently. 

20 The total score, 5 w , is computed as a weighted average over 1 00% from 

the following components: 

The Customer Score and Weight ^customer and^/^r herein, respectively); 

and 

The Transaction Score and Weight fim*** and W i»™* herein, respectively). 
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As the score is a weighted average over 100%, the weights sum up to 100%. The 
formula for computing the total score given all of the aforementioned score is given 
by Formula 3 below. 



C - w 
total customer 



^customemane ^ cmtamentr X ^ customers tr + ^ cmtomeracr X ^ cmtomtracr ) + ^customer* ^customer » + ^AanA 



Formula 3 

In one embodiment, the matching program can also match against open deposits 
transactions and against closed transactions that were credit memo'ed over a given 
1 0 period of time. In one embodiment, the matching routine allows users to place a 
different weight on closed transactions versus open transactions. In doing so, the 
matching program accepts a closed transaction penalty to allow users to adjust the 
scores of transactions if they have been closed. This factor is between 0 and 100% 
and penalizes the total score of the invoice { s t ota i ) with a penalty P by multiplying 

1 5 the score by (1 - P ). In one embodiment, one payment is matched to a transaction. 
Another embodiment matches multiple payments to a transaction. 

In summary, an embodiment of the present invention provides a method and 
system for matching remittances to transactions. The method for matching 

20 remittances to transactions disclosed herein uses a processing paradigm that is not 
complicated to maintain and fosters the use of logic based on the summarization of 
payments. The method disclosed herein also matches remittances to particular 
transactions with relaxed sensitivity to where identifying markers may be placed on a 
remittance and is resistant to typographical data entry errors. Further, the method 

25 disclosed herein is flexible with regards to handling various kinds of information that 



ORCL-2003-030-01 /ACM/G DB/LRG 



35 



can result in accurate, precise matching without discarding or overlooking such 
information. 



In one embodiment, a computer implemented method matches a remittance 
5 to a transaction by receiving remittance lines, transaction information, and matching 
rules wherein the matching rules assign a weight to a parameter considered in the 
matching, computing a weighted matching score corresponding to the parameter 
based upon that weight wherein the matching score corresponds to a probability of 
an accurate and precise match between the remittance and the transaction, and 
1 0 generating a match recommendation based on that weighted matching score. 

One embodiment of the present invention provides significant reduction in 
miss rate (e.g., failing to accurately and precisely match a remittance to a correct, 
corresponding transaction). Advantageously, use of the present embodiment by a 

1 5 business entity can provide a business entity user with a significant savings in what 
must conventionally be expended on research costs associated with unapplied 
receipts (e.g., research conducted by trained personnel to correlate 
unmatched/mismatched receipts to their correct corresponding transactions). Further 
financial advantages can accrue to the concomitant ability to more quickly apply 

20 remittances received, once they are matched to their respective transactions. Thus, 
an embodiment of the present invention promotes commercial efficiency. The 
present embodiment provides a novel process and combination of tools which 
promote matching remittances to transactions in a useful, intuitive way. 

25 An embodiment of the present invention, a method for matching remittances 

based on weighted scoring and fuzzy logic, is thus described. While the present 
invention has been described in particular embodiments, the present invention 
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should not be construed as limited by such embodiments, but rather construed 
according to the following claims and their equivalents. 
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